Fix index schema from st tables.#5145
Conversation
6191d7c to
7e41705
Compare
| index_schema.alias = self | ||
| .find_st_index_accessor_row_by_index_name(index_schema.index_name.as_ref())? | ||
| .map(|row| row.accessor_name); |
There was a problem hiding this comment.
This restores the persisted source_name alias when rebuilding IndexSchema, which fixes the restart/recreate path, but I think auto-migration still has the same issue. auto_migrate_indexes only compares accessor_name and algorithm, not IndexDef.source_name. If a TS module changes the generated source name while keeping the same canonical index name/accessor/algorithm, the migration can succeed without updating st_index_accessor, and the runtime will still call index_id_from_name with the new source name.
Should we reject source_name changes as requiring manual migration, or add a step to update st_index_accessor?
| const TYPESCRIPT_MODULE_WITH_NEW_COLUMNS: &str = r#"import { schema, table, t } from "spacetimedb/server"; | ||
|
|
||
| const users = table( | ||
| { name: "users", public: false }, |
There was a problem hiding this comment.
Can we make the table accessor differ from the canonical table name? The reported issue involved runtime/source index names being built from both table and column accessor names while the stored index used canonical snake_case names. This test covers column accessor divergence but not table accessor divergence because both names are currently users.
Description of Changes
fixes #4701.
IndexSchemawhen build from system tables, wasn't consideringst_index_accessortable to set alias.Module use this alias in ABIs causing reducer's causing runtime panic like
Uncaught No such indexAPI and ABI breaking changes
NA
Expected complexity level and risk
1
Testing
Added a smoketest for typescript, this is more apparent in typescript due to
snake_casename casing results in different canonical and accessor name.